Session-based forwarding

ABSTRACT

The present disclosure discloses a method and network device for session based forwarding. Specifically, the disclosed system receives a first packet in a session, and performs a route lookup to determine a route for the first packet. Then, the system caches a reference to the route and a neighbor in the session, and also caches a reference to the session in a tunnel within which packets in the session are to be forwarded. Based on a comparison between the route version number cached in the session and the route version number in a route table corresponding to the route referenced by a route index in the session, the system determines whether the route is stale. If so, the system performs another route lookup to update the route. Moreover, the system uses cached reference to the session in the tunnel for forwarding subsequent packets in the session.

RELATED APPLICATIONS

This application claims the benefit of priority on U.S. ProvisionalPatent Application 61/732,829, filed Dec. 3, 2012, the entire contentsof which are incorporated by reference.

Related patent applications to the subject application include thefollowing: (1) U.S. Patent Application entitled “System and Method forAchieving Enhanced Performance with Multiple Networking CentralProcessing Unit (CPU) Cores” by Janakiraman, et al., U.S. applicationSer. No. 13/692,622, filed Dec. 3, 2012, attorney docket reference no.6259P186; (2) U.S. Patent Application entitled “Ingress TrafficClassification and Prioritization with Dynamic Load Balancing” byJanakiraman, et al., U.S. application Ser. No. 13/692,608, filed Dec. 3,2012, attorney docket reference no. 6259P191; (3) U.S. PatentApplication entitled “Method and System for Maintaining Derived DataSets” by Gopalasetty, et al., U.S. application Ser. No. 13/692,920,filed Dec. 3, 2012, attorney docket reference no. 6259P192; (4) U.S.Patent Application entitled “System and Method for Message handling in aNetwork Device” by Palkar, et al., U.S. application Ser. No. ______,filed Jun. 14, 2013, attorney docket reference no. 6259P189; (5) U.S.Patent Application entitled “Rate Limiting Mechanism Based on DeviceLoad/Capacity or Traffic Content” by Nambiar, et al., U.S. applicationSer. No. ______ , filed Jun. 14, 2013, attorney docket reference no.6259P185; (6) U.S. Patent Application entitled “Control Plane Protectionfor Various Tables Using Storm Prevention Entries” by Janakiraman, etal., U.S. application Ser. No. ______, filed Jun. 14, 2013, attorneydocket reference no. 6259P188. The entire contents of the aboveapplications are incorporated herein by reference.

FIELD

The present disclosure relates to networking processing performance of asymmetric multiprocessing (SMP) network architecture. In particular, thepresent disclosure relates to a system and method for providingsession-based forwarding in a pipelined forwarding model.

BACKGROUND

A symmetric multiprocessing (SMP) architecture generally is amultiprocessor computer architecture where two or more identicalprocessors can connect to a single shared main memory. In the case ofmulti-core processors, the SMP architecture can apply to the CPU cores.

In an SMP architecture, multiple networking CPUs or CPU cores canreceive and transmit network traffic. While receiving and transmittingthe network traffic, the system may maintain a flow-based engine thattransmits the network traffic on a per-flow basis. Each flow is uniquelyidentified by a session key. To allow for efficient forwarding offlow-based network traffic, a network routing system typically useslongest prefix match to perform route lookup. Specifically, the routingsystem can look up in a route table for next hop information based onwhich Internet Protocol (IP) address provides the longest prefix matchto the destination IP address.

Nevertheless, the longest prefix match lookup may incur excessive costwhen the packets have long IP addresses, e.g., in the scenario of IPv6network. Moreover, because the network topology and conditions canchange dynamically, updating the route table to reflect the routechanges in the flow table can be costly too. As a result, the rate ofnetwork convergence in the event of route changes may be slow with theconventional routing mechanisms that update the route information in theflow table.

BRIEF DESCRIPTION OF THE DRAWINGS

The present disclosure may be best understood by referring to thefollowing description and accompanying drawings that are used toillustrate embodiments of the present disclosure.

FIG. 1 is a diagram illustrating an exemplary wireless networkenvironment according to embodiments of the present disclosure.

FIG. 2 illustrates an exemplary architecture at multiple processingplanes according to embodiments of the present disclosure.

FIG. 3 illustrates an exemplary network forwarding process according toembodiments of the present disclosure.

FIG. 4 is a diagram illustrating exemplary routing tables maintained ina shared memory according to embodiments of the present disclosure.

FIG. 5 illustrates exemplary layer 3 and/or layer 2 packet flow datastructure according to embodiments of the present disclosure.

FIG. 6 illustrates an exemplary route catch table according toembodiments of the present disclosure.

FIGS. 7A-7C illustrates various routing tables according to embodimentsof the present disclosure.

FIGS. 8A-8C illustrates various scenarios in which a network route mayneed to be updated according to embodiments of the present disclosure.

FIG. 9 illustrates an exemplary trie data structure used insession-based forwarding according to embodiments of the presentdisclosure.

FIGS. 10A-10B illustrate processes for session-based forwardingaccording to embodiments of the present disclosure.

FIG. 11 is a block diagram illustrating a system of session-basedforwarding according to embodiments of the present disclosure.

DETAILED DESCRIPTION

In the following description, several specific details are presented toprovide a thorough understanding. While the context of the disclosure isdirected to SMP architecture performance enhancement, one skilled in therelevant art will recognize, however, that the concepts and techniquesdisclosed herein can be practiced without one or more of the specificdetails, or in combination with other components, etc. In otherinstances, well-known implementations or operations are not shown ordescribed in details to avoid obscuring aspects of various examplesdisclosed herein. It should be understood that this disclosure coversall modifications, equivalents, and alternatives falling within thespirit and scope of the present disclosure.

Overview

Embodiments of the present disclosure relate to networking processingperformance. In particular, the present disclosure relates to a systemand method for providing efficient session-based forwarding withmultiple networking central processing unit (CPU) cores. Specifically,the system achieves efficient session-based forwarding by maintaining aversion associated with each route in a session table and determiningwhether a route is stale based on the value of the version associatedwith each route.

According to embodiments of the present disclosure, the conventionalroute cache table that enumerates all destinations on the shared memoryis trimmed down to regular Neighbor table without the need for LPM basedRoute lookup. The packet forwarding pipeline process is optimized byperforming route lookup only once per session flow (assuming that noroute changes during the session). The present disclosure allows forcaching a reference to a route in the session and caching a reference tothe session in a tunnel or a logical interface, and thus not onlyenhancing the conventional per-packet based route lookup to per-flowbased lookup, but also allowing direct access to route information fromthe tunnel or logical interface.

Specifically, with the solution provided herein, a disclosed networkdevice receives a first packet in a session, and performs a route lookupbased on a header of the first packet to determine a route for the firstpacket. Further, the network device caches a reference to the route inthe session such that subsequent packets in the session are routed basedon the cached reference in lieu of subsequent route lookups. Thereference to the route comprises one or more of a route index (which mayadditionally include an equal cost multiple path (ECMP) index), a routeversion number, a neighbor index, and a neighbor index number.

For session based forwarding, the disclosed system compares a route'sversion number in the session against the version number in a routereferred by the index in the session. Likewise, the disclosed systemalso compares the neighbor entry's version number in the session againstthe version number in a neighbor referred by the index in the session.

For tunnel based forwarding, the disclosed system can validate referenceto the session by comparing the source and destination IP addresses.Specifically, the disclosed system can checks the source and/ordestination IP address in the tunnel against the source and/ordestination IP address in the session.

If the disclosed network device determines that the route is stale, thedisclosed network device can perform another route lookup to update theroute with one or more of an updated route index, an updated routeversion number, an updated neighbor index, and an updated neighborversion number. In some embodiments, however, if the disclosed networkdevice determines that the route is stale and the session is inactive,it will delay route lookup until at least one packet is received in thesession.

In some embodiments, at least two paths with identical cost correspondto the route are stored in the route table. Each path is identified by aunique Equal Cost Multiple Path (ECMP) index. When a new ECMP index isadded to the route table, a subsequent session uses the path associatedwith the new ECMP index, but an existing session continues to use anexisting path associated with an existing ECMP index.

In some embodiments, when at least two next hop nodes use Virtual RouterRedundancy Protocol (VRRP), the route is determined to be stale based ondifference between the first neighbor version number cached in thesession and the second neighbor version number corresponding to theroute in the neighbor table.

In some embodiments, if the route determined to be stale, the disclosednetwork device performs another route lookup to update the session withan updated route index and an updated route version number. And if theupdated route index and the updated route version corresponding to ashorter alternative route than the route, the disclosed network deviceforwards subsequent packets in the session using the shorter alternativeroute. In one embodiment, the shorter alternative route is stored in apatricia trie as a child node of a parent node. Specifically, the parentnode corresponds to the route; and, a route version number of the routecorresponding to the parent node is updated/incremented in response tothe child node being inserted in the patricia trie.

In some embodiments, the disclosed network device encapsulates the firstpacket based on information returned from a bridge lookup prior toencrypting the first packet.

Furthermore, the disclosed network device identifies a network interfacethat the first packet is to be transmitted on. Then, the disclosednetwork device sends the first packet to a security engine of thenetwork device to encrypt the first packet, and instructs the securityengine to forward encrypted first packet to the identified networkinterface in lieu of returning the encrypted first packet to a processorwithin the network device.

Computing Environment

FIG. 1 shows an exemplary wireless digital network environment accordingto embodiments of the present disclosure. FIG. 1 includes at least oneor more network controller (such as controller 100), one or more accesspoints (such as access point 160), one or more client devices (such asclient 170), a layer 2 or layer 3 network 110, a routing device (such asrouter 120), a gateway 130, Internet 140, and one or more web servers(such as web server A 150, web server B 155, and web server C 158), etc.

Controller 100 is a hardware device and/or software module that providenetwork managements, which include but are not limited to, controlling,planning, allocating, deploying, coordinating, and monitoring theresources of a network, network planning, frequency allocation,predetermined traffic routing to support load balancing, cryptographickey distribution authorization, configuration management, faultmanagement, security management, performance management, bandwidthmanagement, route analytics and accounting management, etc.

Moreover, assuming that a number of access points, such as access point160, are interconnected with network controller 100. Each access pointsmay be interconnected with zero or more client devices via either awired interface or a wireless interface. In this example, forillustration purposes only, assuming that client 170 is associated withaccess point 160 via a wireless link. Access points generally refer to anetwork device that allows wireless clients to connect to a wirednetwork. Access points usually connect to a router via a wired networkor can be a part of a router in itself.

Furthermore, controller 100 can be connected to router 120 through zeroor more hops in a layer 3 or layer 2 network (such as L2/L3 Network110). Router 120 can forward traffic to and receive traffic fromInternet 140 through gateway 130. Router 160 generally is a networkdevice that forwards data packets between different networks, and thuscreating an overlay internetwork. A router is typically connected to twoor more data lines from different networks. When a data packet comes inone of the data lines, the router reads the address information in thepacket to determine its destination. Then, using information in itsrouting table or routing policy, the router directs the packet to thenext/different network. A data packet is typically forwarded from onerouter to another router through the Internet until the packet gets toits destination.

Gateway 130 is a network device that passes network traffic from localsubnet to devices on other subnets. In the example in FIG. 1, gateway130 is a default gateway that often connects a local network (such asL2/L3 Network 110) to Internet 140. In some embodiments, gateway 130 maybe a part of router 120 depending on the configuration of router 120.

Web servers 150, 155, and 158 are hardware devices and/or softwaremodules that facilitate delivery of web content that can be accessedthrough Internet 140. For example, web server 150 may be assigned an IPaddress of 1.1.1.1 and used to host a first Internet website (e.g.,www.yahoo.com); web server 155 may be assigned an IP address of 2.2.2.2and used to host a second Internet website (e.g., www.google.com); and,web server 158 may be assigned an IP address of 3.3.3.3 and used to hosta third Internet website (e.g., www.facebook.com).

In packet switching networks, a flow generally refers to a sequence ofpackets from a source network/client device to a destinationnetwork/client device, which may be another host, a multicast group, ora broadcast domain. A flow could consist of all packets in a specificsession connection or media stream. Each layer 2 or layer 3 networksession can be uniquely identified by a session key, which may be alayer 3 network session key or a layer 2 network session key. A layer 3network session key generally includes information, such as a sourceInternet Protocol (IP) address, a destination IP address, a protocol, alayer 4 source port, a layer 4 destination port, etc. Moreover, a layer2 network session key generally includes a source Media Access Control(MAC) address, a destination MAC address, Ethernet type, etc. The abovedescribed session keys are maintained in a session table use for sessionmanagement.

General Architecture

FIG. 2 illustrates a general architecture including multiple processingplanes according to embodiments of the present disclosure. Specifically,FIG. 2 includes at least a control plane process 210, two or moredatapath processors 220, a lockless shared memory 260 accessible by thetwo or more datapath processors 220, and a network interface 250.

Control plane process 210 may be running on one or more CPU or CPUcores, such as CP CPU 1 212, CP CPU 2 214, . . . CP CPU M 218.Furthermore, control plane process 210 typically handles network controlor management traffic generated by and/or terminated at network devicesas opposed to data traffic generated and/or terminated at clientdevices.

According to embodiments of the present disclosure, datapath processors220 include a single exception processing CPU, such as a slowpath (SP)processor (e.g., Exception Processing CPU 230) and multiple forwardingCPU, such as fastpath (FP) processors (e.g., Forwarding CPU 1 240,Forwarding CPU 2 242, . . . Forwarding CPU N 248). Only forwardingprocessors are able to receive data packets directly from networkinterface 250. Exception processing processor, on the other hand, onlyreceives data packets from the forwarding processors.

Lockless shared memory 260 is a flat structure that is shared by alldatapath processors 220, and not tied to any particular CPU or CPUs. Anydatapath processor 220 can read any memory location within locklessshared memory 260. Therefore, both the single exception processingprocessor (e.g., Exception Processing CPU 230) and the multipleforwarding processors (e.g., Forwarding CPU 1 240, Forwarding CPU 2 242,. . . Forwarding CPU N 248) have read access to lockless shared memory260, but only the single exception processing processor (e.g., ExceptionProcessing CPU 230) has write access to lockless shared memory 260. Morespecifically, any datapath processor 220 can have access to any locationin lockless shared memory 260 in the disclosed system.

Also, control plane process 210 is communicatively coupled to exceptionprocessing CPU 230, such as a slowpath (SP) CPU, but not forwarding CPU,such as fastpath (FP) processors (e.g., Forwarding CPU 1 240, ForwardingCPU 2 242, . . . Forwarding CPU N 248). Thus, whenever control planeprocess 210 needs information from datapath processors 220, controlplane process 210 will communicate with exception processing CPU 230,such as an SP processor.

Network Forwarding

FIG. 3 illustrates an exemplary network forwarding process according toembodiments of the present disclosure. A typical pipeline process at aFP processor involves one or more of the following operations:

Port lookup;

VLAN lookup;

Port-VLAN table lookup;

Bridge table lookup;

Firewall session table lookup;

Route table lookup;

Packet encapsulation;

Packet encryption;

Packet decryption;

Tunnel de-capsulation; and/or

Forwarding; etc.

Thus, the network forwarding process illustrated in FIG. 3 includes atleast a port lookup operation 300, a virtual local area network (VLAN)lookup operation 305, a port/VLAN lookup operation 310, a bridge lookupoperation 315, a firewall session lookup operation 320, a route lookupoperation 325, a forward lookup operation 330, an encapsulationoperation 335, an encryption operation 340, a tunnel decapsulationoperation 345, a decryption operation 350, and a transmit operation 360.

FIG. 4 is a diagram illustrating exemplary routing tables maintained ina shared memory according to embodiments of the present disclosure.Shared memory 380 can be used to store a variety of tables to assistsoftware network packet forwarding. For example, the tables may include,but are not limited to, a bridge table, a session table, a user table, astation table, a tunnel table, a route table and/or route cache, etc.Specifically, in the example illustrated in FIG. 4, shared memory 400stores at least one or more of a port table 410, a VLAN table 420, abridge table 430, a station table 440, a route table 450, a route cache460, a session policy table 470, a user table 480, etc. Each table isused during network forwarding operations illustrated in FIG. 3 forretrieving relevant information in order to perform proper networkforwarding. For example, port table 410 is used during port lookupoperation to look up a port identifier based on the destination addressof a network packet. Likewise, VLAN table 420 is used during VLAN lookupoperation to look up a VLAN identifier based on the port identifierand/or source/destination address(es). Note that, a table can be used bymultiple network forwarding operations, and each network forwardingoperation may need to access multiple routing tables.

In some embodiments, shared memory 400 is a lockless shared memory.Thus, multiple tables in shared memory 400 can be accessed by multipleFP processors while the FP processors are processing packets receivedone or more network interfaces. If the FP processor determines that apacket requires any special handlings, the FP processor will hand overthe packet processing to the SP processor. For example, the FP processormay find a table entry corresponding to the packet is missed; andtherefore, handing over the packet processing to the SP processor. Asanother example, the FP processor may find that the packet is afragmented packet, and thus hand over the packet processing to the SPprocessor.

A. Packet Flows

As mentioned above, a flow generally refers to a sequence of packetsfrom a source network/client device to a destination network/clientdevice, which may be another host, a multicast group, or a broadcastdomain. A flow could consist of all packets in a specific sessionconnection or media stream. FIG. 5 illustrates exemplary flow packetsaccording to embodiments of the present disclosure. Note that, a layer 2or layer 3 packet flow may include multiple fragmented packets, whichinclude, e.g., a first fragment (or a parent fragment) and one or moresubsequent fragments (or data fragments).

Also, each packet may include multiple portions. For example, a packetwith a L3 packet key 500 may include at least a network layer (layer 3or L3) header that includes L3 source IP 510, L3 destination IP 515, andprotocol 520, a transport layer (layer 4 or L4) header that includes L4source port 525 and L4 destination port 530. As another example, apacket with a L2 packet key 550 may include at least a media accesscontrol layer (layer 2 or L2) header that include source media accesscontrol (MAC) address 560, destination MAC address 570, and Ethernettype 580.

Subsequent fragments include at least a network layer (layer 3 or L3)header, but do not include any transport (layer 4 or L4) header.Transport (layer 4 or L4) header is required for session-basedforwarding, for example, when firewall policies need to be applied tothe packet. Even though subsequent fragments do not include anytransport (layer 4 or L4) header, they are typically applied with thesame session policies as those applied to the first segment.

B. Route Cache

FIG. 6 illustrates an exemplary route catch table according toembodiments of the present disclosure. In the example shown, route cachetable 600 includes fields such as destination IP address 605, next hopinterface 610, gateway MAC address 615, and neighbor information 620,which duplicates a corresponding neighbor entry in a neighbor table. Topopulate route catch table 600, a network device first performs alongest prefix match lookup in the route table based on the destinationaddress (e.g., “1.1.1.1”) of a network packet to find out the next hopinterface corresponding to the destination address (e.g.,Interface_(NH1)). Assuming, for example, the longest prefix match in theroute table for “1.1.1.1” is “1.1.0.0,” which corresponds to next hopinterface of Interface_(NH1). Note that, the next hop interface mayinclude, but is not limited to, a VLAN, a tunnel, and/or a port.

Then, the network device inserts an entry in route cache table 600 withthe destination IP address, the next hop MAC interface resulting fromthe route table lookup, and the default gateway MAC address (e.g.,MAC_(GW1)) that is known to the network device (e.g., a networkcontroller). The inserted entry will also include other information inits corresponding neighbor entry Entry₁ from the neighbor table. In theexample illustrated in FIG. 6, for destination IP address “2.2.2.2,” thenext hop interface is Interface_(NH2), the default gateway MAC addressis MAC_(GW2), and the neighbor information includes neighbor entryEntry₂; for destination IP address “3.3.3.3,” the next hop interface isInterface_(NH3), the default gateway MAC address is MAC_(GW3), and theneighbor information includes neighbor entry Entry₃. Note that, whenmultiple routes exist for a destination IP address, each route willcorrespond to a different next hop interface although the defaultgateway address may be the same. Thus, each route to the samedestination IP address corresponds to a unique entry in the route cachetable.

In some embodiments, route cache table 600 is maintained as a hash tableby applying a hash function on the destination IP address of the packet.Route cache table 600 may introduce a few issues. First, the cost ofmatching longest prefix for each packet can be high. This is especiallytrue in IPv6 network, where the IP addresses become longer thanconventional IPv4 addresses. Second, as the number of hashed entries inroute cache table increases, the cost for looking up route cache table600 also increases accordingly. Third, maintaining the consistency ofroute cache table 600 may result in additional costs.

For example, when the next hop address in a route corresponding to“1.1.0.0” changes in the routing table, the system would have to performa reverse lookup to search for all destination IP addresses for which“1.1.0.0” is the longest prefix match, and update the next hop addressin all of those entries. Therefore, the convergence after a route changeis slow because of the costs involved in maintaining the consistency ofroute cache table 600.

C. Routing Tables

FIGS. 7A-7C illustrate various routing tables according to embodimentsof the present disclosure. The illustrated routing tables in combinationprovide an alternative and an enhancement to the route cache tabledescribe above. Specifically, FIG. 7A illustrates an exemplary routetable 700, which includes a field for version 702, prefix/length 705 anda field for next hop address 710 and also an optional next hop interfacefor routes through P2P interface (not shown). For example, according toroute table 700, the next hop address for “1.0.0.0/8” is IP_(NH1)) andthe version of the route is 100; the next hop address for “0.0.0.0/0” isIP_(NH2), and the version of the route is 101; etc.

FIG. 7B illustrates an exemplary session table 720, which includes atleast the following fields: source IP address 725, destination IPaddress 730, route index 735, route version 740, neighbor index 745,neighbor version 750, etc. Route index 735 may also include a next hopindex in cases where equal cost multiple paths (EMCP) apply. In thefirst example shown in FIG. 7B, the route index corresponding to a routefrom the source IP address “100.100.100.100” to the destination IPaddress “1.1.1.1” is route₁. Also, the corresponding route version forroute₁ is 100; and, the corresponding neighbor index and neighborversion are ARP₁ and 10 respectively. In the second example, due to aneighbor change in route₁, the neighbor index, neighbor version, androute version are updated to ARP₂, 20, and 101 respectively responsiveto the next hop change for route₁.

Note that, the version number 100 for route₁ is the route version numbercorresponding to route entry route₁ in the route table at the time whenthe disclosed system performs the route lookup and insert the referenceto route₁ into session table 720. Likewise, the version number 10 isneighbor ARP₁ is the neighbor version number corresponding to theneighbor entry ARP₁ in the neighbor table at the time when the disclosedsystem insert the reference to APR₁ into session table 720.

FIG. 7C illustrates an exemplary neighbor table 760, which includes atleast the following fields: version 765, index 770, IP address 775, MACaddress 780, VLAN identifier 790, etc. Neighbor table 760 provides amapping between a destination IP address and MAC address. In someembodiments, information in neighbor table 760 can be obtained bytransmitting an Address Resolution Protocol (ARP) request and analyzethe corresponding ARP response. In the example shown in FIG. 7C, for thefirst neighbor with neighbor index number 1, the IP address is10.10.10.10, which corresponds to VLAN 10; the corresponding MAC addressis MAC₁; and the version number is 10. Likewise, for the second neighborwith neighbor index number 2, the IP address is 18.18.18.18, whichcorresponds to VLAN 18; the corresponding MAC address is MAC₂; and theversion number is 20. Further, for the third neighbor with neighborindex number 3, the IP address is 15.15.15.15, which corresponds to VLAN15; the corresponding MAC address is MAC₂; and the version number is 30.The above examples are provided for illustration purposes only.Different neighbors may have the same version number, but their IPaddress and MAC address will be unique.

In addition, there exists a firewall session policy table, whichincludes information, such as permission (e.g., permit or deny access),destination network address translation (DNAT), source network addresstranslation (SNAT), rate limiting, etc. In some embodiments, a flowtable can be used for stateful firewall purposes in addition to firewallpurposes. According to the present disclosure, the firewall sessionpolicy table and/or flow table can be modified to additionally includethe next hop information and version information, and used for routingpurposes.

During operation, the system monitors every session based on flow-baseddestination IP address, which persists through the entire session.Because the value of the destination IP address does not change for aparticular session, information such as those cached in the route cachecan be cached in the session for easier access during the sessioninstead of performing a lookup operation on a packet-by-packet basis. Asmentioned previously in description regarding FIG. 3, a typicalforwarding pipeline includes a bridge lookup operation, a firewallsession policy lookup operation, and subsequent routing operations. Thefirewall session policy lookup operation checks the firewall policybased on the destination IP address of the packets. For example, a usermay be redirected to a captive portal page when the user is trying toaccess a destination IP address of “1.1.1.1” according to the enterprisefirewall policy configurations.

More specifically, the system will be forwarding packets to “1.1.1.1” ina session (or a flow). Accordingly, the system will initiate a routelookup based on the destination IP address of the session, e.g.,“1.1.1.1.” For illustration purposes only, assuming that the routelookup returns a next hop IP address of “10.10.10.10.” The system willthen perform a neighbor lookup based on the resulting IP address of thenext hop. In this example, it is assumed that the neighbor lookupreturns MAC₁ (e.g., 01:02:03:04:05:06) and VLAN identifier V₁₀.

It is important to note that the firewall session policies includesource and destination IP addresses along with other keys. Therefore, inevery session for which the system performs session-based forwarding, ifthe session is determined to be a router session (which means that thesession is not a client-to-client session that the network system cansimply forward the packets by bridging the packets, but a session thatrequires a router to route the packets to the Internet), the system canthen cache the routing lookup results in the session itself.

In another example, one router is configured as the default router.Thus, every packet will be sent to the same MAC address corresponding tothe default router, but the next hop address will be different dependingon the destination IP address of each session. In this example, it ispossible to eliminate all user VLANs and to use only one VLAN to routeall packets to the default router. In addition, a guest VLAN may beconfigured to route all guest traffic to a network controller within theWLAN.

Therefore, the disclosed system may optimize the forwarding pipeline bycaching the routing information in each session. However, it is possiblethat during an active session, a route to the destination IP address maychange. In such scenarios, the disclosed system will update the sessiontable to reflect the route changes. To improve the efficiency in theupdating operations, rather than maintaining a copy of the relevantroute information in the session table, the disclosed system maintains areference to an entry in the route table and a version numbercorresponding to the route reference, as well as a reference to an entryin the neighbor table and a version number corresponding to the neighborreference.

With this solution, the disclosed system no longer needs to perform aroute lookup after a firewall session lookup, because the system canobtain route information directly from the sessions. Neither is itnecessary to maintain a route cache in the system any longer, whichreduces the cost for routing operations compared with other solutions.

Maintenance of Route Consistency

The disclosed system is also able to efficiently maintain theconsistency of the route information in the session table (or flowtable) and the route information in the route table and the neighbortable (or ARP table). Because the reference and version number to eachroute is maintained in the session, any time when a route changes, thesystem will be able to quickly detect the route change based on one ormore of a change in the route reference, route version, neighborreference, and/or neighbor version. Moreover, the system can easilyupdate the session with the route change by updating one or more of theroute reference, route version, neighbor reference, and/or neighborversion to reflect the route change.

Specifically, to detect a route change, for every packet being forwardedin a session, the system de-references the route index and the neighborindex in the session entry to retrieve the corresponding entries in theroute table and the neighbor table. The system then obtains the currentversion number corresponding to the route index in the route table andthe current version number corresponding to the neighbor index in theneighbor table. Next, the system determines whether certain conditionsthat indicate that the route in the session table is stale haveoccurred. For example, the system can determine whether the routeversion number and the neighbor version number maintained in the sessionentry match the current version numbers and/or neighbor index obtainedabove. If either version number in the session table is different fromits corresponding version number in the route table or the neighbortable or if the neighbor index in the session table is different fromits corresponding neighbor index in the neighbor table, then the sessionentry is stable. Therefore, the system will perform a route lookup usinglongest prefix match of the destination IP address of the session, andupdate the route information based on the results from the route lookup.

Note that, in the route table, a version number corresponding to a routeindex changes whenever there is a change in the route, e.g., a change inthe next hop address. On the other hand, in the neighbor table, aversion number corresponding to a neighbor index changes whenever themapping between the IP address and the MAC address of a network node(e.g., a default gateway or a next hop for a particular VLAN) changes,for example, when the Ethernet interface changes.

The following sections describe a few exemplary scenarios in which aroute could be changed during an active session, and how the system willdetect the route change in each scenario. These examples are providedfor illustration only. They are not intended to be an exhaustive list ofall possible scenarios. One skilled in the art can apply the techniquesdisclosed herein to detect other types of route changes withoutdeparting from the spirit of the invention.

A. Route Change

In this scenario, the default gateway's IP address may change during asession because the route gets modified, for example, from “10.10.10.10”at time point t₁ to “18.18.18.18” at time point t₂. In the route table,assuming that, at t₁, the route entry has the version number of 100,index value of 1, prefix/length value of “1.0.0.0/8,” and next hop IPaddress of “10.10.10.10.”

Accordingly, in the session table, at time point t₁, the session entryhas values as shown in session entry 760 in session table 720, e.g.,having a source IP address of “100.100.100.100,” a destination IPaddress of “1.1.1.1,” a route index corresponding to route₁, a routeversion of 100, a neighbor index corresponding to ARP₁, and a neighborversion of 10.

Based on the change above, at time point t₂, the same route entry hasthe version number of 101, index value of 1, prefix/length value of“1.0.0.0/8,” and next hop IP address of “18.18.18.18.”

When the system receives the first packet in the session after the timepoint t₂, the system will detect that the route version in the sessiontable (e.g., 100) does not match the route version in the route table(e.g., 101). Thus, the system will deem the session entry as stale andperform a route lookup to update the session entry.

After the update, the session entry will have the values as shown insession entry 765 in session table 720, e.g., having a source IP addressof “100.100.100.100,” a destination IP address of “1.1.1.1,” a routeindex corresponding to route₁, a route version of 101, a neighbor indexcorresponding to ARP₂, and a neighbor version of 20. Note that, theroute version has changed from 100 to 101; the neighbor index haschanged from ARP₁ (corresponding to “10.10.10.10” in neighbor table 760)to ARP₂ (corresponding to “18.18.18.18” in neighbor table 760); and, theneighbor version has changed from 10 (corresponding to APR₁ in neighbortable 760) to 20 (corresponding to ARP₂ in neighbor table 760).

Similarly, when a route is deleted rather than modified, the system willalso detect a mismatch in the version numbers between the session tableand the route table, because the corresponding route entry in the routetable is missing. Therefore, the system will initiate a route lookup tosearch for a new route to the destination IP address based on thelongest prefix match to the current route table (in which the originalroute was deleted), and update the session table with the informationregarding the new route.

Also, note that, the route lookup is performed when the system receivesa packet in the session after time point t₂. Thus, if no packet isreceived which indicates that the client is in an idle state, then thesession entry will remain to be stale despite that a change has occurredin the route table at time point t₂. This is because when the client isidle, the client is not using the route, and thus there is no need tospend any resources on updating the route for an idle client.Furthermore, if the session entry remains to be stale for an excessiveamount of time because no client is using the session, the session entrywill eventually be removed without ever being updated with the routechange at all.

B. Equal Cost Multiple Paths (ECMP)

FIG. 8A illustrates a use case scenario of ECMP, where there exitsmultiple paths with equal cost. In this example, a packet in a sessionflow from node A 800 to a destination address in L2/L3 Network 880 needsto be forwarded by the disclosed system. Further, node A 800 isinterconnected with two different next hop nodes, which are next hop A810 and next hop B 820. Each of the two different next hop nodescorresponds to a unique path to the destination address with equal cost.

For illustration purposes, assuming that, next hop A 810 is associatedwith the IP address of “10.10.10.10” and is pre-existing at time pointt₁. Thus, at time point t₁, in the route table, the route entry has theversion number of 101, index value of 1, prefix/length value of“1.0.0.0/8,” and next hop IP address of “10.10.10.10” corresponding tonext hop A 810.

In addition, assuming that, at time point t₂, a new route with equalcost from the source address to the destination address through next hopB 820 becomes available during the session. Assuming that, next hop B820 is associated with the IP address of “18.18.18.18.”

Accordingly, the route table will be updated. Thus, the same route entrynow has the version number of 101, index value of 1, prefix/length valueof “1.0.0.0/8,” and next hop IP address of “10.10.10.10; 18.18.18.18”corresponding to both next hop A 810 and next hop B 820. In thisexample, each next hop IP address corresponds to a unique ECMP index. Inaddition to caching the route index, the session may also cache the ECMPindex in the cases involving ECMPs. Note that, the version numberremains the same, but the ECMP index is increased with the additionalECMP route becoming available.

Subsequently, any new sessions to a destination address for which“1.0.0.0/8” provides the longest prefix match will be using the new ECMProute corresponding to next hop B 820 with the IP address of“18.18.18.18.” Nevertheless, any existing route will continue to usenext hop A 810 with the IP address of “10.10.10.10,” because the routeversion number has not changed. As a result, the system will determinethat the route through next hop A 810 is not stale and does not need tobe changed or updated.

This scheme can be particularly useful when traffic from a private IPnetwork is to be forwarded to two or more networks corresponding todifferent uplink service providers (e.g., AT&T® and Verizon®) via two ormore different IP addresses, such as IP₁ and IP₂. It is desirable thatthe traffic to the first service provider is only transmitted via IP₁,and the traffic to the second service provider is only transmitted viaIP₂. Therefore, the traffic from users of different service providerswill not get mixed with each other.

C. Virtual Router Redundancy Protocol (VRRP)

Virtual Router Redundancy Protocol (VRRP) is a computer networkingprotocol that provides for automatic assignment of available IP routersto participating hosts. This increases the availability and reliabilityof routing paths via automatic default gateway selections on an IPsub-network. The VRRP protocol achieves this by creation of virtualrouters, which are an abstract representation of multiple routers, i.e.,master and backup routers, acting as a group. The default gateway of aparticipating host is assigned to the virtual router instead of aphysical router. If the physical router that is routing packets onbehalf of the virtual router fails, another physical router is selectedto automatically replace it. The physical router that is forwardingpackets at any given time is called the master router. Thus, at anygiven time, there is only one physical router that is activelyforwarding the traffic.

FIG. 8B illustrates a use case scenario of VRRP, where there exits twoalternative paths with alternative next hop nodes. In this example, apacket in a session flow from node A 800 to a destination address inL2/L3 Network 880 needs to be forwarded by the disclosed system.Further, node A 800 is interconnected with two different next hop nodes,which are next hop A 810 and next hop B 820. Each of the two differentnext hop nodes corresponds to the same virtual router under VRRP 815.Therefore, at any given time, traffic from node A 800 will be able toreach next hop C 830 via either next hop A 810 or next hop B 820 but notboth, and the traffic will continue to be forwarded to next hop C 830via L2/L3 network 880.

Assuming that, at time point t₁, next hop A 810 is active under VRRP 815and corresponds to the IP address of “10.10.10.10.” Thus, in theneighbor table, the neighbor entry has the version number of 10, indexvalue of 1, IP address of “10.10.10.10,” MAC address of MAC_(A)(corresponding to next hop A 810), and VLAN identifier value of V₁₀.

At time point t₂, assuming that next hop A 810 fails, and next hop B 820starts to function as the virtual router. Therefore, in the neighbortable, the same neighbor entry now has the version number of 11, indexvalue of 1, IP address of “10.10.10.10,” MAC address of MAC_(B)(corresponding to next hop B 820), and VLAN identifier value of V₁₀.

Because the neighbor version has changed from 10 to 11, the system willdetermine that the route has become stale. Consequently, the system willperform a route lookup and update the session entry in the session tablewith the new neighbor version number.

D. Shorter Alternative Route

FIG. 8C illustrates a use case scenario in which an alternative shorterroute is added during the session. In this example, a packet in asession flow from node A 800 to a destination node D 890 is initiallyforwarded through next hop B 820 and L2/L3 Network 880. Subsequently,assuming that node A 800 is interconnected with an additional next hopnode, which is next hop A 810, and that next hop A 810 is furtherinterconnected with destination node D 890. Here, for illustrationpurposes only, it is assumed that next hop A is associated with an IPaddress of “1.1.0.0” and that next hop B is associated with an IPaddress of “1.0.0.0.” Therefore, there are two alternative routesbetween node A 800 and destination node D 890. Specifically, trafficfrom node A 800 will be able to reach destination node D 890 via nexthop A 810, which provides a shorter route than the original route vianext hop B 820 and L2/L3 Network 880.

In some embodiments, route information can be maintained in a patriciatrie. A patricia trie generally refers a space-optimized trie datastructure, where each node with only one child is merged with its child.As a result, every internal node has at least two children. Unlike inregular tries, edges can be labeled with sequences of elements as wellas single elements. This makes them much more efficient for small sets(especially if the strings are long) and for sets of strings that sharelong prefixes.

FIG. 9 illustrates an exemplary patricia trie used in session-basedforwarding according to the present disclosure. In this given example,patricia trie 900 includes at least root node 920, node 940, and node960, which correspond to “0.0.0.0/0,” “1.0.0.0/8,” and “1.1.0.0/16”respectively. Note that, node 940 is a child node of root node 920.Also, node 960 is a child node of node 940 and a grandchild node of rootnode 920. Therefore, in the patricia trie illustrated in FIG. 9, a childnode always has a longer prefix match than its parent node.

Furthermore, when a new route is inserted into a patricia trie as a newnode (e.g., assuming that node 960 is inserted as a child node of node940), the disclosed system performs at least two operations: First, thesystem will add the new route (e.g., “1.1.0.0/16”) to the route tablewith a new route index that is different from the route index of theoriginal route corresponding to the parent node in the patricia trie.Second, the system will increase, in the route table, the version numberof the route corresponding to the parent node of the inserted node(e.g., the version number of route “1.0.0.0/8” will be increased from100 to 101; note that the route “1.0.0.0/8” corresponds to parent node940 of the inserted node 960 in this example).

Because the version number of the route corresponding to the parent nodein the patricia trie gets updated, the corresponding route entry (e.g.,“1.0.0.0/8”) becomes stale due to the difference in the route versionnumber in the session table (e.g., 100) and in the route table (e.g.,101). Thus, the system will perform a route lookup to update the routeinformation. As a result, the route lookup will return the shorterroute, e.g., “1.1.0.0/16”, with a new route index instead of theoriginal route (e.g., “1.0.0.0/8”). Thus, subsequent traffic from thesame source node to the same destination node will be forwarded throughthe updated shorter route.

Note that, as mentioned above, when traffic from a private IP network isto be forwarded to two or more networks corresponding to differentuplink service providers (e.g., AT&T® and Verizon®) via two or moredifferent IP addresses, such as IP₁ and IP₂, it is desirable that thetraffic to the first service provider is only transmitted via IP₁, andthe traffic to the second service provider is only transmitted via IP₂.In such scenarios, typically a network address translation (NAT) ofeither source IP address or destination IP address of the packets isinvolved. Nevertheless, when no NAT operation is involved and a shorterroute is found during a session as in the example illustrated above inthe description of FIG. 8C and FIG. 9, it would be desirable to switchto a shorter route during an existing session.

Note that, the route lookup is performed only when the system receives apacket in a session. Thus, if in a second session where the new route“1.1.0.0/16” can be used, but no packet is received in the secondsession due to the client being idle, then the session entry will remainto be stale despite that a new and shorter route has been inserted inthe route table. This is because when the client is idle, the client isnot using the route, and thus there is no need to spend any resources onupdating the route for an idle client. Furthermore, if the session entryremains to be stale for an excessive amount of time because no client isusing the session, the session entry will eventually be removed withoutever being updated with the route change at all.

It is important to note that, in the present disclosure, only activepurging is used, and there is not background purging involved.Therefore, a session is updated only when there are active trafficactivities in the session. No background process is used to update thesession entries, because there is no need to utilize the resource for asession when the session is idle.

Caching Session Information in Secured Tunnels

In some embodiments, a computing environment as illustrated in FIG. 1may have a L2/L3 network between controller 100 and access point 160. Insuch embodiments, a L2 or L3 tunnel (e.g., a Generic RoutingEncapsulation (GRE) tunnel) can be established between controller 100and access point 160 for transmission of packets to and from client 170.A tunnel is generally represented as (source IP address, destination IPaddress, protocol, L4 attributes), and is usually identified by a uniquesession key.

As illustrated in FIG. 3, a typical network forwarding process includes,inter alia, a bridge lookup 315 (e.g., on an Ethernet packet formattedas IEEE 802.3 packet), a firewall session lookup 320, a route lookup325, a forwarding lookup 330, etc. Then, if it is determined that thepacket needs to be transmitted via a tunnel between a controller and anaccess point, the packet is further encapsulated with an outer header,e.g., a GRE header, to be converted to an IEEE 802.11 packet format. Theencapsulated packet in IEEE 802.11 format again goes through the sameseries of network forwarding process, e.g., a firewall session lookup320, a route lookup 325, a forwarding lookup 330, etc., before it can beproperly forwarded to its destination.

In a system as illustrated in FIG. 2, one of datapath processors 220(e.g., FP CPU 1 240, FP CPU 2 242, . . . , or FP CPU N 248) will performa session and/or route lookup, then send the packet to a security engine(not shown) for encryption. The encrypted (and encapsulated) packet willbe returned back to datapath processors 220, which will then forward theencrypted and encapsulated packet to its corresponding network interface250.

In some embodiments, datapath processors 220 may perform encapsulationprior to sending the packet to the security engine for encryption. Inaddition, datapath processors 220 may instruct the security engine whichdestination network interface 250 is associated with the packet.Therefore, after the security engine completes the encryption of thepacket, the security engine can directly forward the packet to itscorresponding destination network interface 250 without returning theencapsulated packet to datapath processors 220.

Specifically, the system will first perform a route and neighbor (e.g.,ARP) lookup, which will return a MAC address and a VLAN identifiercorresponding to the destination IP address in the packet. Next, basedon the combination of MAC and VLAN identifier, the system performs abridge lookup, which will return a destination network interface thatcan be either a port identifier or a tunnel identifier.

Based on the MAC address corresponding to the destination IP address,the system can determine whether the packet is a unicast packet or amulticast packet. If the packet is a unicast packet, the system can usea unicast key to encrypt the packet. On the other hand, if the packet isa multicast packet, the system can use a tunnel or multicast key toencrypt the packet.

Furthermore, based on the destination network interface, the system candetermine whether the packet needs to encapsulated. For example, if thedestination network interface returned from the bridge lookup isassociated with a GRE tunnel, then the system can determine that thepacket will need to be encapsulated with the GRE headers before beingforwarded to its destination. Typically, in order to perform anencapsulation, the system needs to know the tunnel information for thepacket, which includes the source and destination IP addresses(available in the header of the packet), the transmission protocol(which can be determined based on the tunnel identifier), and L4attributes associated with the packet (which are usually cached in thetunnel). Therefore, upon successful bridge lookup, the system would beable to perform an encapsulation of the packet based on the informationreturned from the bridge lookup.

Note that, if the system identifies that a packet needs to be encryptedand encapsulated, the system can perform the encapsulation prior to theencryption, and thereby avoiding the need for the packet to be returnedto datapath processors after encryption. This simplified packet flowwithin the system, e.g., from the FP processors to security enginedirectly to network interface without the packet being returned to theFP processors by the security engine, allows for dramatic performanceenhancement in a high performance controlling and switching system.

After session entries are cached in a tunnel, the system can combine thetunnel encapsulation operations with the L2/L3 lookups (such as,firewall session lookup 320, route lookup 325, forwarding lookup 330,etc.), and thereby avoid feeding the network forwarding process twicewith the same packet (but differently formatted as IEEE 802.3 for thefirst time and IEEE 802.11 for the second time). In one embodiment, alink from the tunnel to the session (e.g., index value of thecorresponding session entry in the session table) is maintained wherethe session further includes routing information as described above. Thelink will provide quick access to important routing information storedin session, and therefore allowing for determination of whether thesystem can leverage the session information for simplified session-basedforwarding (e.g., where no complex firewall operations are required forthe session).

Furthermore, for subsequent packets within the same session, the systemcan use the cached link to the session entry to retrieve the routinginformation, and thus avoiding feeding the packets through the sessionforwarding pipeline process. In summary, rather than feeding everypacket through the session forwarding pipeline twice (first with IEEE802.3 format and second with IEEE 802.11 format), the present disclosureallows for the first packet in a flow to be sent through the sessionforwarding pipeline once whereby the encryption and encapsulationoperations are combined into the pipeline process, and for anysubsequent packets to bypass the session forwarding pipeline byproviding a direct link from tunnel to the corresponding session entry,which caches the corresponding routing information returned from theroute lookup performed for the first packet in the flow.

Processes for Session-Based Forwarding

FIGS. 10A-10B are flowcharts illustrating exemplary processes forsession-based forwarding. Specifically, FIG. 10A illustrates anexemplary session-based forwarding process in which route references arecached in the session to avoid per-packet based route lookup. Duringoperation, the disclosed system receives a first data packet in asession (operation 1000). The system then performs a route lookup todetermine a route for the first packet (operation 1005). In addition,for session-based forwarding, the disclosed system caches a reference tothe route and the neighbor in the session (operation 1010). Further, thedisclosed system optionally caches a reference to the session and theneighbor in a tunnel in cases where tunnel-based forwarding mechanism isused (operation 1015). The reference to the route includes one or moreof a route index, a route version number, a neighbor index, and aneighbor version number. In some embodiments, the tunnel can be a GREtunnel within which packets in the session are to be forwarded. Notethat, caching the reference to the session in the tunnels allows fordirect access to the route information from the tunnel.

Moreover, the disclosed system compares a first route version numbercached in the session with a second route version number cached in aroute (operation 1020), and then determines whether the route is stale(operation 1025). In some embodiments, the system further compares afirst neighbor index and version number cached in the session with asecond neighbor index and version number corresponding to the route in aneighbor table, and determines that the route is stale if the firstneighbor index or version number is different from the second neighborindex or version number.

If the system determines that the route is stale, the system willperform another route lookup to update the route (operation 1030).Specifically, the system may update the route with one or more of anupdated route index, an updated route version number, an updatedneighbor index, and an updated neighbor index number. Nevertheless, insome embodiments, if the system determines that the route is stale butthe session is inactive, the system will delay route lookup until atleast one packet is received in the session.

In some embodiments, at least two paths with identical costcorresponding to the route are stored in the route table; and, each pathis identified by a unique Equal Cost Multiple Path (ECMP) index. When anew ECMP index is added to the route table, a subsequent session usesthe path associated with the new ECMP index, but an existing sessioncontinues to use an existing path associated with an existing ECMPindex.

In some embodiments, at least two next hop nodes use Virtual RouterRedundancy Protocol (VRRP), the route is determined to be stale based onthe difference between a first neighbor version number cached in thesession and a second neighbor version number corresponding to the routein the neighbor table.

Next, when tunnel-based forwarding mechanism is used, the system can usethe cached reference to the session in the tunnel for forwardingsubsequent packets in the session (operation 1035). Thus, the systemonly needs to perform a route lookup for the first packet in a sessionunless there are route changes during the session that prompts foranother route lookup to update the route.

In other embodiments, when a route is determined to be stale, the systemperforms another route lookup to update the session with an updatedroute index and an updated route version number. Such updated routeindex and updated route version number may correspond to a shorteralternative route than the original route. If so, the system willforward subsequent packets in the session using the shorter alternativeroute. In one embodiment, the shorter alternative route is stored in apatricia trie as a child node of a parent node. Specifically, the parentnode corresponds to the route; and, a route version number correspondingto the parent node is increased when a child node is inserted in thepatricia trie.

FIG. 10B illustrates an exemplary session-based forwarding process inwhich a packet is encapsulated prior to being forwarded to a securityengine such that the security engine can forward encrypted packetdirectly to the corresponding network interface. During operation, thedisclosed system performs a bridge lookup based on a received packet(operation 1040). Then, the system encapsulates the packet based oninformation returned from the bridge lookup (operation 1045). Also, thesystem identifies a network interface that the packet is to betransmitted on (operation 1050). Then, the system sends the packet to asecurity engine for encryption (operation 1055). Furthermore, the systeminstructs the security engine to forward the encrypted packet to theidentified network interface (operation 1060). Thus, unlike conventionalforwarding process, the security engine does not need to return thepacket to a process within the system and can directly forward theencrypted packets to a network via the identified network interface.

System for Session-Based Forwarding

FIG. 11 is a block diagram illustrating a network device system forsession-based forwarding according to embodiments of the presentdisclosure. Network device 1100 includes at least a network interface1110 capable of communicating to a wired network, a shared memory 1120capable of storing data, a exception processing processor core 1130capable of processing network data packets, and one or more forwardingprocessor cores, including forwarding processor core 1142, forwardingprocessor core 1144, . . . , forwarding processor core 1148, which arecapable of processing network data packets. Moreover, network device1100 may be used as a network switch, network router, networkcontroller, network server, etc. Further network device 1100 may serveas a node in a distributed or a cloud computing environment.

Network interface 1110 can be any communication interface, whichincludes but is not limited to, a modem, token ring interface, Ethernetinterface, wireless IEEE 802.11 interface (e.g., IEEE 802.11n, IEEE802.11ac, etc.), cellular wireless interface, satellite transmissioninterface, or any other interface for coupling network devices. In someembodiments, network interface 1110 may be software-defined andprogrammable, for example, via an Application Programming Interface(API), and thus allowing for remote control of the network device 1100.

Shared memory 1120 can include storage components, such as, DynamicRandom Access Memory (DRAM), Static Random Access Memory (SRAM), etc. Insome embodiments, shared memory 1120 is a flat structure that is sharedby all datapath processors (including, e.g., exception processingprocessor core 1130, forwarding processor core 1142, forwardingprocessor core 1144, . . . , forwarding processor core 1148, etc.), andnot tied to any particular CPU or CPU cores. Any datapath processor canread any memory location within shared memory 1120. Shared memory 1120can be used to store various tables to assist session-based packetforwarding. For example, the tables may include, but are not limited to,a bridge table, a session table, a user table, a station table, a tunneltable, a route table and/or route cache, etc. It is important to notethat there is no locking mechanism associated with shared memory 1120.Any datapath processor can have access to any location in locklessshared memory in network device 1100.

Exception processing processor core 1130 typically includes a networkingprocessor core that is capable of processing network data traffic.Exception processing processor core 1130 is a single dedicated CPU corethat typically handles table managements. Note that, slowpath processorcore 1130 only receives data packets from one or more forwardingprocessor cores, such as forwarding processor core 1142, forwardingprocessor core 1144, . . . , forwarding processor core 1148. In otherwords, exception processing processor core 1130 does not receive datapackets directly from any line cards or network interfaces. Only theplurality of forwarding processor cores can send data packets toexception processing processor core 1130. Moreover, exception processingprocessor core 1130 is the only processor core having the write accessto shared memory 1120, and thereby will not cause any data integrityissues even without a locking mechanism in place for shared memory 1120.

Forwarding processor cores 1142-1148 also include networking processorcores that are capable of processing network data traffic. However, bydefinition, forwarding processor cores 1142-1148 only performs “fast”packet processing. Thus, forwarding processor cores 1142-1149 do notblock themselves and wait for other components or modules during theprocessing of network packets. Any packets requiring special handling orwait by a processor core will be handed over by forwarding processorcores 1142-1148 to exception processing processor core 1130.

Each of forwarding processor cores 1142-1148 maintains one or morecounters. The counters are defined as a regular data type, for example,unsigned integer, unsigned long long, etc., in lieu of an atomic datatype. When a forwarding processor core 1142-1148 receives a packet, itmay increment or decrement the values of the counters to reflect networktraffic information, including but not limited to, the number ofreceived frames, the number of received bytes, error conditions and/orerror counts, etc. A typical pipeline process at forwarding processorcores 1142-1148 includes one or more of: port lookup; VLAN lookup;port-VLAN table lookup; bridge table lookup; firewall session tablelookup; route table lookup; packet encapsulation; packet encryption;packet decryption; tunnel de-capsulation; forwarding; etc.

Moreover, forwarding processor cores 1142-1148 each can maintain afragment table. Upon receiving a data fragment without informationnecessary for session processing (e.g., a transport layer or L4 header),forwarding processor cores 1142-1148 will queue the data fragments intheir own fragment table, and perform various fragment table managementtasks.

Periodically, exception processing processor core 1130 may receive aquery corresponding to one or more forwarding processor cores 1142-1148from a control plane process. Exception processing processor core 1130identifies one or more memory locations in the shared memory storingdata for the one or more forwarding processor cores 1142-1148corresponding to the query, retrieves one or more data values at theidentified memory locations, and responds to the query. In someembodiments, exception processing processor core 1130 can furtheraggregate retrieved data values to generate an aggregated data value,and respond to the query based on the aggregated data value.

According to embodiments of the present disclosure, network servicesprovided by network device 1100, solely or in combination with otherwireless network devices, include, but are not limited to, an Instituteof Electrical and Electronics Engineers (IEEE) 802.1x authentication toan internal and/or external Remote Authentication Dial-In User Service(RADIUS) server; an MAC authentication to an internal and/or externalRADIUS server; a built-in Dynamic Host Configuration Protocol (DHCP)service to assign wireless client devices IP addresses; an internalsecured management interface; Layer-3 forwarding; Network AddressTranslation (NAT) service between the wireless network and a wirednetwork coupled to the network device; an internal and/or externalcaptive portal; an external management system for managing the networkdevices in the wireless network; etc.

The present disclosure may be realized in hardware, software, or acombination of hardware and software. The present disclosure may berealized in a centralized fashion in one computer system or in adistributed fashion where different elements are spread across severalinterconnected computer systems coupled to a network. A typicalcombination of hardware and software may be an access point with acomputer program that, when being loaded and executed, controls thedevice such that it carries out the methods described herein.

The present disclosure also may be embedded in non-transitory fashion ina computer-readable storage medium (e.g., a programmable circuit; asemiconductor memory such as a volatile memory such as random accessmemory “RAM,” or non-volatile memory such as read-only memory,power-backed RAM, flash memory, phase-change memory or the like; a harddisk drive; an optical disc drive; or any connector for receiving aportable memory device such as a Universal Serial Bus “USB” flashdrive), which comprises all the features enabling the implementation ofthe methods described herein, and which when loaded in a computer systemis able to carry out these methods. Computer program in the presentcontext means any expression, in any language, code or notation, of aset of instructions intended to cause a system having an informationprocessing capability to perform a particular function either directlyor after either or both of the following: a) conversion to anotherlanguage, code or notation; b) reproduction in a different materialform.

As used herein, “digital device” generally includes a device that isadapted to transmit and/or receive signaling and to process informationwithin such signaling such as a station (e.g., any data processingequipment such as a computer, cellular phone, personal digitalassistant, tablet devices, etc.), an access point, data transfer devices(such as network switches, routers, controllers, etc.) or the like.

As used herein, “access point” (AP) generally refers to receiving pointsfor any known or convenient wireless access technology which may laterbecome known. Specifically, the term AP is not intended to be limited toIEEE 802.11-based APs. APs generally function as an electronic devicethat is adapted to allow wireless devices to connect to a wired networkvia various communications standards.

As used herein, the term “interconnect” or used descriptively as“interconnected” is generally defined as a communication pathwayestablished over an information-carrying medium. The “interconnect” maybe a wired interconnect, wherein the medium is a physical medium (e.g.,electrical wire, optical fiber, cable, bus traces, etc.), a wirelessinterconnect (e.g., air in combination with wireless signalingtechnology) or a combination of these technologies.

As used herein, “information” is generally defined as data, address,control, management (e.g., statistics) or any combination thereof. Fortransmission, information may be transmitted as a message, namely acollection of bits in a predetermined format. One type of message,namely a wireless message, includes a header and payload data having apredetermined number of bits of information. The wireless message may beplaced in a format as one or more packets, frames or cells.

As used herein, “wireless local area network” (WLAN) generally refers toa communications network links two or more devices using some wirelessdistribution method (for example, spread-spectrum or orthogonalfrequency-division multiplexing radio), and usually providing aconnection through an access point to the Internet; and thus, providingusers with the mobility to move around within a local coverage area andstill stay connected to the network.

As used herein, the term “mechanism” generally refers to a component ofa system or device to serve one or more functions, including but notlimited to, software components, electronic components, electricalcomponents, mechanical components, electro-mechanical components, etc.

As used herein, the term “embodiment” generally refers an embodimentthat serves to illustrate by way of example but not limitation.

It will be appreciated to those skilled in the art that the precedingexamples and embodiments are exemplary and not limiting to the scope ofthe present disclosure. It is intended that all permutations,enhancements, equivalents, and improvements thereto that are apparent tothose skilled in the art upon a reading of the specification and a studyof the drawings are included within the true spirit and scope of thepresent disclosure. It is therefore intended that the following appendedclaims include all such modifications, permutations and equivalents asfall within the true spirit and scope of the present disclosure.

While the present disclosure has been described in terms of variousembodiments, the present disclosure should not be limited to only thoseembodiments described, but can be practiced with modification andalteration within the spirit and scope of the appended claims. Likewise,where a reference to a standard is made in the present disclosure, thereference is generally made to the current version of the standard asapplicable to the disclosed technology area. However, the describedembodiments may be practiced under subsequent development of thestandard within the spirit and scope of the description and appendedclaims. The description is thus to be regarded as illustrative ratherthan limiting.

What is claimed is:
 1. A method comprising: receiving, by a networkdevice, a first packet in a session; performing, by the network device,a route lookup based on a header of the first packet to determine aroute for the first packet; and caching, by the network device, areference to the route and a neighbor in the session such thatsubsequent packets in the session are routed based on the cachedreference in lieu of subsequent route lookups.
 2. The method of claim 1,wherein the reference to the route comprises one or more of: a routeindex, a route version number, a neighbor index, and a neighbor indexnumber.
 3. The method of claim 1, further comprising: comparing, by thenetwork device, a first route version number cached in the session and asecond route version number in a route table corresponding to the routereferenced by a route index in the session; and determining, by thenetwork device, that the route is stale in response to the first routeversion number being different from the second route version number. 4.The method of claim 3, further comprising: comparing, by the networkdevice, a first neighbor index and version number cached in the sessionwith a second neighbor index and version number in a neighbor tablecorresponding to the route referenced by the route index in the session;and determining, by the network device, that the route is stale inresponse to the first neighbor index or version number being differentfrom the second neighbor index or version number.
 5. The method of claim4, further comprising: in response to determining that the route isstale, performing another route lookup to update the route with one ormore of an updated route index, an updated route version number, anupdated neighbor index, and an updated neighbor version number.
 6. Themethod of claim 4, further comprising: in response to determining thatthe route is stale and the session is inactive, delaying route lookupuntil at least one packet is received in the session.
 7. The method ofclaim 3, wherein at least two paths with identical cost corresponding tothe route are stored in the route table, each path being identified by aunique Equal Cost Multiple Path (ECMP) index.
 8. The method of claim 7,wherein, when a new ECMP index is added to the route table, a subsequentsession uses the path associated with the new ECMP index and an existingsession continues to use an existing path associated with an existingECMP index.
 9. The method of claim 4, wherein, when at least two nexthop nodes use Virtual Router Redundancy Protocol (VRRP), the route isdetermined to be stale based on difference between the first neighborversion number cached in the session and the second neighbor versionnumber corresponding to the route in the neighbor table.
 10. The methodof claim 3, further comprising: in response to the route determined tobe stale, performing another route lookup to update the session with anupdated route index and an updated route version number; in response tothe updated route index and the updated route version corresponding to ashorter alternative route than the route, forwarding subsequent packetsin the session using the shorter alternative route.
 11. The method ofclaim 10, wherein the shorter alternative route is stored in a patriciatrie as a child node of a parent node, wherein the parent nodecorresponds to the route, and wherein a route version number of theroute corresponding to the parent node is increased in response to thechild node being inserted in the patricia trie.
 12. The method of claim1, further comprising: caching, by the network device, a reference tothe session in a tunnel within which packets in the session are to beforwarded, thereby allowing direct access to the route from the tunnel.13. The method of claim 1, further comprising: encapsulating, by thenetwork device, the first packet based on information returned from abridge lookup prior to encrypting the first packet; identifying, by thenetwork device, a network interface that the first packet is to betransmitted on; sending the first packet to a security engine of thenetwork device to encrypt the first packet; and instructing the securityengine to forward encrypted first packet to the identified networkinterface in lieu of returning the encrypted first packet to a processorwithin the network device.
 14. A network device having a symmetricmultiprocessing architecture, the network device comprising: a pluralityof CPU cores; a network interface to receive one or more data packets;and a memory whose access is shared by the dedicated CPU core and theplurality of CPU cores; wherein the plurality of CPU cores are to:receive a first packet in a session; perform a route lookup based on aheader of the first packet to determine a route for the first packet;and cache a reference to the route and a neighbor in the session suchthat subsequent packets in the session are routed based on the cachedreference in lieu of subsequent route lookups.
 15. The network device ofclaim 14, wherein the reference to the route comprises one or more of: aroute index, a route version number, a neighbor index, and a neighborindex number.
 16. The network device of claim 14, wherein the pluralityof CPU cores are further to: compare a first route version number cachedin the session and a second route version number in a route tablecorresponding to the route referenced by a route index in the session;and determine that the route is stale in response to the first routeversion number being different from the second route version number. 17.The method of claim 16, wherein the plurality of CPU cores are furtherto: compare a first neighbor index and version number cached in thesession with a second neighbor index and version number in a neighbortable corresponding to the route referenced by the route index in thesession; and determine that the route is stale in response to the firstneighbor index or version number being different from the secondneighbor index or version number.
 18. The network device of claim 17,wherein the plurality of CPU cores are further to: perform another routelookup to update the route with one or more of an updated route index,an updated route version number, an updated neighbor index, and anupdated neighbor version number in response to determining that theroute is stale.
 19. The network device of claim 17, wherein theplurality of CPU cores are further to: delay route lookup until at leastone packet is received in the session in response to determining thatthe route is stale and the session is inactive.
 20. The network deviceof claim 16, wherein at least two paths with identical costscorresponding to the route are stored in the route table, each pathbeing identified by a unique Equal Cost Multiple Path (ECMP) index. 21.The network device of claim 20, wherein, when a new ECMP index is addedto the route table, a subsequent session uses the path associated withthe new ECMP index and an existing session continues to use an existingpath associated with an existing ECMP index.
 22. The network device ofclaim 17, wherein, when at least two next hop nodes use Virtual RouterRedundancy Protocol (VRRP), the route is determined to be stale based ondifference between the first neighbor version number cached in thesession and the second neighbor version number corresponding to theroute in the neighbor table.
 23. The network device of claim 16, whereinthe plurality of CPU cores further to: perform another route lookup toupdate the session with an updated route index and an updated routeversion number in response to the route determined to be stale; forwardsubsequent packets in the session using the shorter alternative route inresponse to the updated route index and the updated route versioncorresponding to a shorter alternative route than the route.
 24. Thenetwork device of claim 23, wherein the shorter alternative route isstored in a patricia trie as a child node of a parent node, wherein theparent node corresponds to the route, and wherein a route version numberof the route corresponding to the parent node is increased in responseto the child node being inserted in the patricia trie.
 25. The networkdevice of claim 14, wherein the plurality of CPU cores are further to:cache a reference to the session in a tunnel within which packets in thesession are to be forwarded, thereby allowing direct access to the routefrom the tunnel.
 26. The network device of claim 14, wherein theplurality of the CPU cores are further to: encapsulate the first packetbased on information returned from a bridge lookup prior to encryptingthe first packet; identify a network interface that the first packet isto be transmitted on; send the first packet to a security engine of thenetwork device to encrypt the first packet; and instruct the securityengine to forward encrypted first packet to the identified networkinterface in lieu of returning the encrypted first packet to a processorwithin the network device.
 27. A non-transitory computer-readablestorage medium storing embedded instructions for a plurality ofoperations that are executed by one or more mechanisms implementedwithin a network device having a symmetric multiprocessing architecture,the plurality of operations comprising: receiving a first packet in asession; performing a route lookup to determine a route for the firstpacket; caching a reference to the route in the session; caching areference to the session and a neighbor in a tunnel within which packetsin the session are forwarded; comparing a first route version numbercached in the session with a second route version number in a routetable corresponding to the route referenced by a route index in thesession; determining whether the route is stale based on the first andsecond route version numbers; performing another route lookup to updatethe route in response to determining that the route is stale; and usingcached reference to the session in the tunnel for forwarding subsequentpackets in the session.